System and Method for Acceleration of a Secure Transmission Over Satellite

ABSTRACT

A broadband communication system with improved latency is disclosed. The system employs acceleration of secure web-based communications over a satellite communication network. In accordance with aspects of the invention, secure protocol acceleration is employed such that required protocol signals transmitted from a computer employing a web browser may be intercepted by a remote terminal. To insure that the browser will continue transmitting data, the remote terminal generates required acknowledgment and security signals to continue the secure communication, which may then transmitted back to the computer. Meanwhile, the received protocol signals may be converted by the remote terminal for transmission through the satellite communications system in a format appropriate for that communication medium. Aspects of the invention further include a hub or similar device for communicating with the satellite communications system.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of and claims priority to U.S.patent application Ser. No. 14/271,937 filed on May 7, 2014 and entitled“System and Method For Acceleration of a Secure Transmission OverSatellite”, which is a divisional application of and claims priority toU.S. patent application Ser. No. 13/596,509 filed on Aug. 28, 212 andentitled “System and Method For Acceleration of a Secure TransmissionOver Satellite,” which is a continuation of U.S. patent application Ser.No. 10/303,722 filed on Nov. 26, 2002 and entitled “System and MethodFor Acceleration of a Secure Transmission Over Satellite,” which is acontinuation-in-part of U.S. patent application Ser. No. 09/781,554filed Feb. 13, 2001 and entitled “System and Method For Internet PageAcceleration Including Multicast Transmissions,” which claims priorityfrom U.S. Provisional Patent Application No. 60/262,647 filed on Jan.22, 2001 and entitled “Real-Time HTML Multicast System” and U.S.Provisional Patent Application No. 60/182,537 filed Feb. 15, 2000 andentitled “System and Method For Internet Page Acceleration IncludingMulticast Transmission,” each of which is incorporated by referenceherein.

FIELD OF THE INVENTION

The present invention relates to broadband communication systems. Moreparticularly, the present invention relates to a communications systemthat communicates between a central telecommunications network and atleast one remote station using a satellite communication link.

BACKGROUND

Various data caching systems are well known in the art for storing thecontents of Internet pages, Web or data pages, in a cache memory forlocal display by a Web browser. For example, previously when the WorldWide Web (WWW) was accessed primarily through a relatively slow dial-uplink, a Web browser would often include a list of favorite Web sites.The entire contents of each Web site in the list would be downloadedovernight and continuously updated so that the experience associatedwith accessing a Web site contained in the list would be improved.

Some browsers include the ability to parse the contents of a Web page sothat referenced objects, such as links to other Web pages, can bepre-fetched and stored in cache, thereby facilitating quick access tothe linked Web pages.

Currently, there are many cache systems for the Internet. Some cachesystems are located at a server, some are located at a client, and stillothers are distributed throughout the computer networks forming theInternet, such as being distributed between an Internet Service Provider(ISP), a hub and/or a central server location. See, for example, U.S.Pat. No. 5,727,129 to Barrett et al., U.S. Pat. No. 5,761,683 to Loganet al., and WO 99/16201 invented by K. L. El-Rafie. Additionally,companies such as Cidera (SkyPre-fetch), StarBurst, Cisco, and Teleglobeprovide distributed caching systems.

More recently, communications between distributed cache engines havebeen standardized in accordance with ICP (Internet Cache Protocol) RFC2186. Consequently, in many of the distributed cache systems, a proxyserver configuration is utilized in which a user selects a particularcache server a proxy server. Thereafter, all requests from the user aresent to the cache server for processing. Thus, by simply adjusting thedefault settings on the Web browser, the user is able to redirect allrequests to a selected cache server.

Nevertheless, none of the aforementioned caching systems addressesproblems that are associated with an asymmetric communication channel,such as a satellite network channel or a cable television channel. Forexample, a message and its corresponding reply in an asymmetricalchannel often experience an excessive delay. In a satellite-basedsystem, the delay is caused by the relatively long distances associatedwith the communication path. In a cable network or for a remote Internetaccess site, the delay is often caused by the number of users occupyingthe system.

To address performance problems in asymmetric systems having excessivedelays, systems have been proposed that parse a referencing page at aheadend, or a hub, site of the system. The system then immediatelydownloads related links and/or objects identified by parsing and/orbased on the prior user selections to a remote terminal requesting thepage referencing the related links and/or objects. The downloadingfunction is automatic for these known systems and typically occurswithout receiving additional requests from a requesting terminal. See,for example, U.S. Pat. No. 5,929,850 to Broadwin et al., and WO 99/08429invented by B. L. Carneal et al. Such automatic downloading cachingsystems, however, can be problematic in that the downstream bandwidth isnot efficiently utilized. Unneeded data is often automatically sent to aremote terminal without being based on a specific request from theremote terminal, and when, in fact, the remote terminal requires nofurther data. Such automatic downloading systems also often require oneor more proxy servers. The use of automatic downloading and proxyservers reduces efficiency and increases latency based on overheadrequirements that are associated with each proxy server.

What is needed is a technique for reducing the latency experienced at aremotely located station when requesting web pages and objects from acommunications network, such as the Internet.

Moreover, transmission of information by establishing a TransmissionControl Protocol/Internet Protocol (TCP/IP) connection over a satellitehas emphasized the latency problems associated with the use of suchincompatible transmission techniques. To overcome those delays, Gilathas commercially sold devices utilizing embedded TCP acceleration sinceat least as early as 1994, embedded within the modem. Such pageacceleration techniques have concentrated primarily on TCP/IP pageacceleration. To date, such systems have been unable to achievesatisfactory delays using a secure protocol layer running above aTransmission Control Protocol/Internet Protocol layer. For example, withregard to transmissions utilizing a Secure Sockets Layer (SSL), delaysare dramatically increased because the SSL protocol generates a greatdeal of traffic including full handshakes, resumed handshakes, keyexchanges, and a host of other signals.

SSL, for example, is a commonly deployed security protocol for providinga secure connection between two devices communicating over the Internet.Critical to this technique is the use of identifiers for identifying theauthorized participants of the secure communication such thatintermediate devices simply pass data to one of the two devicesunchanged, and without deciphering the encrypted data. The SecureSockets Layer runs above the TCP/IP layer. SSL is designed to allow anyprotocol that is designed to run over TCP/IP to also run over the SSL.The handshaking protocol typically includes numerous steps be performedfor exchanging indications of the SSL version to be used, ciphersettings, keys for generating a premaster secret, for example, and manymore.

Thus, where TCP/IP acceleration may be employed to reduce latencyassociated with standard web browsing over a satellite communicationsystem, a problem arises where the transfers between the web browser andthe web host or server are encrypted. First, given the numerous signalexchanges required by the SSL protocol for establishing a secureconnection and the inherent delays associated with transmission ofInternet communications over a satellite communication system,establishing an SSL connection over a satellite introduces considerablelatency. Such communications become prohibitively slow, rendering use ofsecure communications over satellite systems undesirable. Second, inHTTPS, the connection between the client browser and the web server isencrypted such that it may not be possible to interpret the pages or topre-fetch the pages at the hub server. The handshake protocol componentof SSL, for example, includes steps for authenticating the identity ofeach respective device through the exchange of SSL Certificates thathave been “signed” by a Certificate Authority or other company thebrowser/computer trusts, and through the exchange of encryption keys.For example, SSL uses X509 certificates. These security measures mayprevent acceleration of secure Internet communications using standardTCP/IP acceleration. Accordingly, a new protocol is required fortransmitting secure communications over a satellite where the link isencrypted using HTTPS, SSL, or other secure web based protocols.

There is a need, therefore, for a technique for reducing the latencyexperienced at a remotely located station when requesting secureInternet communications between the remote station and web hosts througha satellite communications system.

SUMMARY

Aspects of the present invention provides a technique for reducing thelatency experienced at a remotely located station when requesting webpages and objects from a communications network, such as the Internet.

The advantages of the present invention are provided by a caching systemand method for a satellite communications system in which a remoteclient station, such as a VSAT-based client station, requests a selecteddata page from a host station, such as a server, that is connected to acommunications network, such as the Internet. According to theinvention, the remote client station is coupled to the communicationsnetwork through the satellite communications system. The requested datapage can be a home page and/or a favorite page for the remote clientstation. A cache storing information forming at least a portion of atleast one data page receives the request for the selected data page anddetermines whether at least a portion of information forming theselected data page is stored in the cache. When information forming theselected page is stored in the cache, the cache sends the informationforming the selected page that is stored in the cache to the remoteclient station. The cache also sends a request to the host stationthrough the satellite communications system for information forming theselected data page that is not stored in the cache. Accordingly, thecache can receive periodic updates of the information forming the basepage from a server hosting the base page through, for example, amulticast transmission or through a tunnel.

In an aspect of the present invention, the cache parses the base pageand identifies objects, such as an in-line object or adynamically-embedded object, contained in the base page. The cache thensends at least one identified object contained in the base page and thatis stored in the cache to the remote client station when the at leastone identified object contained the base page is stored in the cache.Subsequently, the cache sends a request to the host station through thesatellite communications system for each identified object contained inthe base page that is not stored in the cache. When the remote clientstation receives the base page and the at least one identified objectfrom the cache, the remote client station displays the informationforming the base page and the at least one identified object withoutdelay. Alternatively, the remote client station displays the informationforming the base page for a predetermined period of time beforedisplaying the at least one identified object contained in the basepage. As yet a further alternative, the cache can send the at least oneidentified object to the remote client station after a predeterminedperiod of time elapses after the base page is sent to the remote clientstation.

As an even further alternative, the cache can include a linked list ofobjects stored in the cache, in which case the cache sends at least oneidentified object contained in the base page and that is included in thelinked list of objects to the remote client station when the at leastone identified object contained the linked list of objects is stored inthe cache. The cache then sends a request to the host station throughthe satellite communications system for each identified object containedin the linked list of objects that is not stored in the cache. The cachecan also send the linked list of objects to the remote client station sothat the remote client station can synchronize a list of objects storedat the remote client station with the received linked list of objectsstored in the cache. The cache can receive a list of objects stored atthe remote client station from the remote client station so that thecache can synchronize the linked list of objects stored in the cachewith the received list of objects stored at the remote client station.Additionally or in the alternative, the cache can receive informationfrom the remote client station relating to an object handling capabilityof a browser operating in the remote client station. The cache can thendetermine which objects contained in the requested base page to send tothe remote client station based on the received information relating tothe object handling capability of the browser.

According to one aspect of the invention, the cache pre-fetches therequested data page and at least one object contained in the requesteddata page before the request for the data page is received from theremote client station. The cache can then form a data cluster from atleast one object contained in the requested data page, and sends thedata cluster to the remote client station. Alternatively, the cachemultiplexes a plurality of objects contained in the requested data page,and/or compresses the data cluster before sending the data cluster tothe remote client station.

Where the data page includes information forming a base page, the cachemay send the base page to the remote client station when informationforming the base page is stored in the cache and subsequently send arequest to the host station through the satellite communications systemfor information forming the base page that is not stored in the cache.Where the remote client station stores information forming the requesteddata page, the cache may send information to the remote client stationindicating that the requested data page stored in the remote clientstation does not need to be updated when information stored in the cacheforming the requested data page is up to date.

The remote client station may be co-located with the cache, and/orcoupled to the cache through a satellite communication link. Forexample, the cache may have a first portion and a second portion suchthat the remote client station is co-located with the first portion ofthe cache and is coupled to the second portion of the cache through asatellite communication link. In one embodiment of the presentinvention, the second portion of the cache can be connected to thecommunications network. In another embodiment of the present invention,the cache includes a third portion that is coupled to the communicationsnetwork, and the second portion of the cache is coupled to the thirdportion of the cache through another satellite communication link.

An embodiment of the present invention also provides multicast systemthat has a server content evaluator and a server content cache. Theserver content evaluator is connected to a computer network, such as theInternet, that contains a plurality of stored pages of information eachhaving a predetermined format, such as HTML. The server contentevaluator determines whether a particular page is capable of beingmulticast to a plurality of client applications and assigns a uniqueindex number to each page determined to be capable of being multicast toa plurality of client applications. The server content cache is coupledto the server content evaluator and stores index numbers that areassigned to pages of information that have been determined to be capableof being multicast to a plurality of client applications. The servercontent evaluator receives a request from a client application for aselected page of information over, for example, a satellitecommunication link, and sends the index number for the selected page tothe client application when the selected page has an assigned indexnumber stored in the server content cache. Accordingly, the servercontent evaluator receives the selected page of information from thecomputer network when the selected page of information does not have anassigned index number, determines whether the selected page is capableof being multicast to a plurality of client applications, and assigns aunique index number to the selected page when the selected page isdetermined to be capable of being multicast to a plurality of clientapplications. The server content evaluator then sends the assigned indexnumber for the selected page to the client application.

The multicast system also includes a server multicast engine that iscoupled to the server content evaluator. The server multicast enginesends the selected page of information to the client application whenthe server content evaluator determines that the selected page ofinformation does not have an assigned index number, receives theselected page of information from the computer network and then assignsthe unique index number to the selected page.

An aspect of the invention a client content synchronizer that receivesthe request from the client application for the selected page ofinformation, may send the request for the selected page of informationto the server content evaluator. Subsequently, the client contentsynchronizer receives the index number assigned to selected page ofinformation from the server evaluator. A client content cache coupled tothe client content synchronizer stores pages of information, such thateach page of information has an assigned index number. The clientcontent synchronizer sends the received index number for the selectedpage of information to the client content cache and receives theselected page of information corresponding to the received index number.The client content synchronizer then sends the selected page ofinformation to the client application. A client multicast engine iscoupled to the client multicast cache that receives the selected page ofinformation from a server multicast engine when the selected page ofinformation is not stored in the client content cache.

Further aspects of the invention address the need for reducing thelatency experienced at a remotely located station when requesting webpages and the like and exchanging confidential information using securetransmissions between a web server and an Internet computer including abrowser, over satellite communications systems. Aspects of the presentinvention address this need through a system and method for performingsecure protocol acceleration. One aspect of the present inventionprimarily relates to the encryption of data above the transport leveland may include encryption of the data at the application layer. Anotheraspect of the invention involves certificate handling and may furtherinvolve a technique for generating security certificates.

In accordance with aspects of the invention, secure protocolacceleration is employed such that the required protocol signalstransmitted from a computer using a web browser may be intercepted by aremote terminal. To insure that the browser will continue transmittingdata, the remote terminal may generate required acknowledgment signalsand security signals necessary to continue the secure communication.Such signals may then be transmitted to the browser. Meanwhile, theintercepted protocol signals may be converted for transmission throughthe satellite communications system in a format appropriate for thatcommunication medium. Further aspects of the invention involveforwarding signals and data from the browser and the associatedcomputer, through the satellite communications system, to the webserver, and an exchange of information from the web host to the computerin a reverse manner.

Aspects of the invention further may include a hub or similar devicecommunicating with the satellite communications system. A secureconnection between that device and the web server may be maintained bysimulating a continuous secure connection between the computer and theweb server. By transmitting required acknowledgment signals, anddynamically generating security signals, components of the system maymaintain the flow of data transmitted from the devices participating ina secure communication while the data is in fact transmitted over asecure satellite link in a format conducive to such transmissions.

Further aspects of the invention relate to distributed certificatesharing which may involve generation of multiple certificates forestablishing secure links or secure sublinks between the componentsemployed in the communication system. A further aspect of the inventioninvolves manual and/or automatic addition of certificate authoritywithin the secure network, as optionally may be chosen by the user ofsuch a system.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIGS. 1A and 1B are schematic block diagrams of a broadbandcommunications network incorporating the present invention;

FIG. 2 is a schematic block diagram of a portion of the broadbandcommunications network shown in FIGS. 1A and 1B that provides asatellite-based real-time HTML multicast system according to the presentinvention;

FIG. 3 is a schematic block diagram of a portion of the broadbandcommunications network shown in FIGS. 1A and 1B that provides a pageaccelerating system according to the present invention;

FIG. 4 shows a simplified data flow diagram for a web page accessfunction for a VSAT network having a page accelerator system accordingto the present invention;

FIG. 5 shows a simplified data flow diagram for a web page accessfunction for a VSAT network having a page acceleration system that usesobject pre-fetching according to the present invention; and

FIG. 6 is a flowchart showing a process used by an RTA for providingpage acceleration according to the present invention;

FIG. 7A is a simplified schematic block diagram illustrating aconventional secure connection between a web browser and a web server;

FIG. 7B is a simplified schematic block diagram illustrating theconnections between the various subcomponents creating a secureconnection between a web browser and a web server over a satellitecommunication system in accordance with a preferred embodiment of thepresent invention;

FIG. 8 is a schematic block diagram of a portion of an exemplarycommunications network illustrating a page accelerating system forcommunications over a secure communications network in accordance withone aspect of the present invention;

FIG. 9 shows a simplified diagram illustrating the transmission ofsignals between the various component parts of a secure communicationsnetwork in accordance with one aspect of the invention; and

FIG. 10 is a flowchart illustrating a simplified process for dynamicallygenerating a certificate.

DETAILED DESCRIPTION

FIGS. 1A and 1B show schematic block diagrams of broadbandcommunications network 100 in which the present invention can beutilized. Broadband communications network 100 includes a plurality ofWeb servers 101, 102 and 103 that are coupled together via atelecommunications or computer network 104, such as the Internet (Web).Web servers 101, 102 and 103 operate in a well-known manner as hostdevices that store information, such as Web or data pages.

Telecommunications network 104, when embodied as the Internet, caninclude a plurality of routers 105-113, a plurality of cache engines 114and 115, and one or more Very Small Aperture Terminal (VSAT) hubs 116.Routers 105-113 can be clustered in a plurality of sub-networks 117 and118 that are interconnected via an Internet Backbone 119. Sub-networksthat are connected directly to Internet backbone 119 are commonlyreferred to as Tier 1 point-of-presence (POP) networks. While onlyservers 101-103, routers 105-113, cache engines 114 and 115, VSAT hub116 and subnetworks 117 and 118 are shown in FIGS. 1A and 1B as part ofcommunications network 100, it should be understood that more or fewerof each component can be part of communications network 100.

Telecommunications network 104 is interconnected to a plurality ofremotely-located stations, or terminals, 120, such as a VSAT-enabledpersonal computer (PC-VSAT) 121 and/or a PC 122 that is coupled totelecommunications network 104 through one or more remote VSAT stations123. Remote VSAT station 123 can include an integral cache 124 and/or acache engine 125 containing a cache. Remote stations 120 can be coupledto Web servers 101-103 through one or more satellites 126 and 127, andone or more VSAT hubs 128. VSAT hub 128 can include an integral cache129 and/or cache engine 130 containing a cache. While only remotestations 121 and 122, satellites 126 and 127, and VSAT hub 128 are shownin FIGS. 1A and 1B as part of communications network 100, it should beunderstood that more or fewer of each component can be part ofcommunications network 100.

In operation, requests for specific data are made by remote stations 120and sent to various Web servers throughout telecommunications network104. Typically, the “round trip” latency between the time that a requestis made (i.e., sent) and the time that a reply to the request isperceived by a user is a minimum of 500 ms, plus any time delayexperienced for both the request and reply to traversetelecommunications network 104 (i.e., the Internet). In reality, thedelays in traversing Internet 104 can be substantial, particularlythrough the middle portion of Internet backbone 119, which carries themajority of the Internet traffic. The latency experienced at aremotely-located station 120 is particularly acute. Moreover, thelatency is compounded because a typical web page can contain, forexample, 10 to 80 objects that each may be retrieved. Accordingly, eachobject is sequentially requested across the satellite link (i.e.,through satellite 126), thereby leading to a significant delay as eachobject is retrieved. Even when multiple connections (e.g., two to four)are opened, the latency between request and reply can still beuncomfortably long for a user.

The present invention balances speed requirements for reduced latencywith network efficiency, thereby achieving a pleasant user experiencewithout filling the capacity of a satellite downlink channel withunnecessary data. For example, when a new web page is requested by aremote station 120, the present invention queries a local cache storagefor the base page of the requested web page. Such a local cache storagecan be contained with the requesting remote station and/or a cache 124and/or 125 located in remote VSAT station 123. In situations when therequested base page has been stored in a local cache, the base page canbe immediately retrieved for the remote station. Accordingly, the localcache storage can be automatically periodically updated by, for example,cache engine 129 using any suitable protocol, such as Internet CacheProtocol (ICP). The ICP can be modified so that data is received fromVSAT-coupled cache servers, such as cache engine 129, is compatible withthe IP multicast protocol. The ICP can also be modified for allowingremote stations 120 and/or VSAT hub 128 to specify home pages and/orfavorite pages. The base page can also be extracted directly from thehome page location within a browser located on a remote station 120.Favorite pages can also be identified based on a statisticaldetermination of accessed pages, or on a frequency that a page isaccessed.

According to one aspect of the invention, when a base page is located incache storage in a remote station 120, the cached page is parsed foridentifying any in-line objects contained in the page. Alternatively, alocal cache storage can also contain a linked list of in-line objectsthat are associated with particular base pages and that are also storedin the local cache. When a requested page is determined not to haveobjects contained in the linked list, the base page of the requestedpage is parsed for generating a list of objects that are referencedwithin the base page. Thereafter, the local cache in a remote station120 can be checked for determining whether the in-line objects arepresent. When the local objects are also present, the base page cancontinue loading normally.

In situations when a base page is present in a cache locally at a remotestation 120, but the objects within the base page are not, the remotestation sends a modified GET message to VSAT hub 128 indicating whichparticular page is being accessed by the remote station. Cache engine129 at VSAT hub 128 then pre-loads objects associated with the requestedbase page by parsing the base page for identifying any objectsassociated with the base page, and issues a request for the associatedobjects. Rather than sending all objects or parts of the objects to theremote station as the objects are received at VSAT hub 128, VSAT hub 128can optionally be configured to compile the received objects into amultiplexed data cluster that can, in turn, be compressed. After theremote station has loaded all or part of the base page, the remotestation sends a GET request to VSAT hub 128 for requesting themultiplexed data cluster of objects. VSAT hub 128 then sends themultiplexed data cluster to the remote station where the compressed datacluster is decompressed and/or demultiplexed into the individual objectsfor use by the base page.

Loading of all or part of a base page prior to requesting the objectsassociated with the base page has the advantage that a user is allowedto halt the request before large amounts of data objects associated withthe base page are transmitted over, for example, satellite 126.According to one aspect of the present invention, portions of the textof a base page can be displayed for a fraction of a second before theobjects associated with the base page are automatically requested,thereby allowing high-speed browsing without filling the satellite linkwith large objects, such as picture, video, and/or audio files, that areassociated with the base page. Another aspect of the present inventionprovides that index markers from VSAT hub 128 to a remote station thatindicate to the local cache storage of the remote station that contentsstored in the local cache are indeed up-to-date and no new data isrequired to be downloaded.

When one or more Web pages and/or associated objects, such as Microsoft™Yahoo™ and/or Netscape™ home pages, are frequently requested by aplurality of terminal stations, the present invention updates cachesassociated with a plurality of terminal devices using, for example,multicast protocols that allow for efficient transmission of cache dataover a satellite network. Details of a multicast transmission system inaccordance with the present invention will be described below.

When a local cache in a remote station 120 does not include a requestedpage and the objects associated with the requested page, normally arequest is then made to Internet 104 for retrieving the necessary data.A request for a domain name server (DNS) look-up can be made from aremote station 120 to VSAT hub 128. According to the invention, VSAT hub128 can optionally store a version of the DNS tables in cache engine 129to immediately return the IP address for the desired web server to therequesting remote station 120. When a locally stored DNS table isavailable at VSAT hub 128, an immediate look-up is executed. When a DNStable is located remotely from VSAT hub 128, VSAT hub 128 requests theIP address of the desired Web server from the remotely located DNS(FIGS. 1A and 1B) in a well-known manner. In either event, VSAT hub 128initiates the request for the desired web page directly to the retrievedIP address for obtaining and returning the base page to the requestingremote station. Thus, the delay of transmitting the IP address acrossthe satellite from the remote station and receiving the request back issubstantially reduced.

For example, VSAT hub 128 retrieves a desired base page from a Webserver, such as Web server 10. The base page is then transmitteddirectly to the requesting remote station 120, while being processed byVSAT hub 128. That is, the received base page is parsed at VSAT hub 128and/or compiled for identifying any objects associated with the basepage. Identified objects are subsequently requested directly by VSAT hub128, thereby avoiding any delays associated with satellite link 126.VSAT hub 128 then assembles the objects for transmission to remotestation 120. Meanwhile, at the remote station 120, the base page ispartially and/or completely loaded. Optionally, portions of the text ofa base page can be displayed for a fraction of a second before theobjects associated with the base page are automatically requested, asdescribed above. When the downloading of the page is not aborted, arequest is made to VSAT hub 128 to return a multiplexed data cluster ofobjects assembled at VSAT hub 128. In this manner, the satellite linkbetween remote station 120 and VSAT hub 128 is not congested withnumerous large objects that are often not wanted by a user.Alternatively, aborting the downloading of a page can generate a specialuser request that is forwarded to VSAT hub 128 so that the objectsassociated with the aborted page are prevented from being forwarded toremote station 120, thereby preventing link congestion.

Alternatively, in situations when it is difficult or inconvenient todetermine when a user has actually viewed all or a portion of the basepage, the present invention waits a predetermined period of time, suchas 300 ms, before a remote station 120 automatically requests theobjects associated with a requested page from VSAT hub 128.

When VSAT hub 128 parses a base page, VSAT hub 128 can communicate toand/or receive from remote station 120 a list of all objects requested.Consequently, when the objects are different, VSAT hub 128 can requestany additional objects or discard any objects that are not likely to beutilized. For example, the Web browser on a remote station 120 can beconfigured with additional software for a new type of Java language orfile format. Consequently, the Web browser on the remote station canrequire more objects than anticipated by VSAT hub 128. Alternatively, aremote station 120 can include outdated software that cannot process asmany objects that have been automatically requested by VSAT hub 128. Ineither situation, it is often desirable for VSAT hub 128 and remotestation 120 to synchronize their object requests prior to utilizing thedownlink bandwidth of the satellite filling requests for objects. Thisis equally applicable when some, but not all, of the objects areavailable in a local cache at a remote station 120. Accordingly, it canbe desirable for VSAT hub 128 to wait until a specific request forobjects (i.e., in the form of an object list) is received from remotestation 120 before forwarding objects to remote station 120.

Conventional cache engines only parse the base page looking for in-lineobjects, such as data files and other page links. This type of parsing,however, is not efficient for current Web pages, which can containrelatively sophisticated objects, such as dynamically-embedded objects.Accordingly, it is often necessary to compile the Web page fordetermining the presence of more sophisticated objects. For example, thepresent invention can include a Java compiler that is associated withbase page parsing and/or a cache for identifying dynamically-embeddedobjects, thereby providing significant speed enhancements overconventional cache engines. Additionally and/or alternatively, thepresent invention can parse other types of dynamic web pages, such asExcel™ files, for identifying dynamic objects contained therein.

Alternatively, a hub-based caching mechanism of the present inventioncan use the Web response for identifying the cache contents. (Incontrast, conventional techniques for identifying objects associatedwith a requested base page are based on a Web request.) The alternativeapproach of parsing a Web response increases the probability of a cache“hit” at the hub cache engine, as well as at the remote cache engine.Although additional traffic is generated between VSAT hub 128 andInternet web servers by this alternative approach, the data transmittedfrom VSAT hub 128 to a remote station 120 can be significantly reduced,thereby increasing the efficiency of the satellite link.

Yet another aspect of the invention utilizes tunneling between variouslocations within communications network 100 to further reduce latencyassociated with multiple open connections. Tunneling allows a processrunning at a remote station 120 to communicate directly with a processlocated remotely from remote station 120, such as to a process on theother side of a satellite link. For example, as shown in FIGS. 1A and1B, a tunnel 131 can be formed between a remote station 120 and a VSAThub 128. Similarly, a tunnel 132 can be formed between a remote station120 and one or more web servers, such as server 102, located anywherewithin telecommunications network (Internet) 104. Further, a tunnel 133can be formed between a remote station 120 and/or one or more servers,such as server 103, within a selected sub-network, such as sub-network118, that form a point of presence (POP) with telecommunications network(Internet) 104. Tunnel 133 provides the advantage of avoiding latencyassociated with the most congested part of the Internet, such as theInternet backbone 43. Tunneling also allows encrypting in a well-knownmanner for transferring sensitive data over the entire path of thetunnel. Moreover, the tunneling aspect of the invention can be used in acommunication network that does not utilize a satellite link.

Various Web servers, routers, cache engines, and hubs can be configuredto contain a page accelerator process that parses a base page requestfrom a remote station 120 and assembles a multiplexed data cluster ofobjects for the requested base page. For example, a page acceleratorprocess can be located within VSAT hub 116. Objects associated with arequested base page that are forwarded to VSAT hub 116, assembled anddistributed to the requesting remote station 120. The transmissionacross the satellite link can be via multicasting, thereby reducinglatency based on establishing a connection. Page acceleration, accordingto the present invention, is particularly effective when the systemmultiplexes multiple objects into clusters and forwards the clusters inbulk.

When a favorite page or home page update is implemented, the home pageor favorite page can be updated on a periodic basis. Alternatively, alocal cache engine associated with the home or favorite page can bequeries for determining whether the page has been updated. Any updatecan be replicated to any cache; such as cache 129 associated with VSAThub 128 and/or any cache associated with remote stations 120, such ascache 124.

Alternatively, the present invention provides that a persistent lowerlayer protocol connection can be formed between applications so thatthere is no need to open and close connections associated with eachobject, thereby reducing latency. This aspect of the present inventionis particularly useful across a satellite link or in areas experiencinglong delay, such as across Internet backbone 119 to remote networksites.

Additionally, latency can be further reduced by utilizing eliminatingthe need to send acknowledgements across satellites 126 and/or 127. Forexample, a TCP acceleration mechanism can be utilized for allowing localclosing of connections by locally providing finish and acknowledgecommunication commands, thus substantially reducing latency timeassociated with TCP acknowledgements and eliminating the need forsynchronizing or acknowledging connections across the satellite link.

When objects are parsed that are associated with multiple Web servers, afurther enhancement for reducing latency is to assemble the objectrequests into separate lists associated with each Web server and then toforward the requests separately. This is particularly useful when Webbypass links, such as through satellite 127, are utilized for speedingthe process of accessing remote portions of communications network 100.

A VSAT hub, such as VSAT hubs 116 and 128, can also store cookies thatare associated with the respective servers accessed by a remote station120 so that there is no requirement for the remote station 120 to send alengthy cookie with a “GET” request for a new web address. Further, sucha VSAT hub that stores cookies for a remote station has the informationcontained in the cookie that can be used when parsing and/or compiling arequested base page.

As yet a further enhancement of the present invention, a list of objectsassociated with a requested base page can be determined at a locationthat is “remote” from a remote station 120, such as remote VSAT hub 116.Alternatively, a VSAT hub, such as VSAT hub 128, can determine the listof objects associated with a requested base page and forward the list toanother VSAT hub, such as VSAT hub 117. VSAT hub 117 then contacts theappropriate Web server (i.e., Web server 101) and requests all objectscontained in the list. VSAT hub 117 then assembles a multiplexed datacluster of objects received from the Web server at a relatively highrate of speed with a corresponding reduced latency because of theproximity of VSAT hub 117 to Web server 101. The multiplexed datacluster generated by VSAT hub 117 (compressed or uncompressed) is thenbe forwarded via satellite 127 back to VSAT hub 128, thereby eliminatingdelays associated with Internet backbone 119.

As previously noted, the various embodiments of the present inventioncan include a multicast transmission system for transmitting the samedata to multiple clients simultaneously. Such a multicast system isuseful for transmitting information that is frequently accessed byremote stations 120, such as the Microsoft™, Yahoo™ and Netscape™ homepages. The multicast transmission system can also be used, for example,for transmitting “non-optional” advertisement handlings and forintegrating customized training information with other availableexternal content.

FIG. 2 is a schematic block diagram of a portion of broadbandcommunications network 100 (FIGS. 1A and 1B) that provides asatellite-based real-time HTML multicast system 200 according to thepresent invention. For simplicity, FIG. 2 shows only the functionalblocks of the multicast transmission system of the present invention.System 200 includes a hub or server node 201 and a plurality of clientnodes 202, although only a single client node 202 is shown in FIG. 2.Hub node 201 is connected to telecommunications network 104 (FIGS. 1Aand 1B), such as the Internet (WWW). Alternatively, telecommunicationsnetwork 104 can also be a local area network (LAN) or a wide areanetwork (WAN) that, in turn, is connected to the Internet.Telecommunications network 104 includes information that is preferablystored in the form of hypertext mark-up language (HTML) pages. Hub node201 is communicatively coupled to each client node 202 over a satellitecommunication link utilizing a satellite 231 of a satellite network in awell-known manner.

In one embodiment of the multicast system of the present invention, hubnode 201 corresponds to, for example, VSAT hub 117, and client node 202corresponds to, for example, VSAT hub 128. In another embodiment of themulticast system of the present invention, hub node 201 corresponds to,for example, VSAT hub 117, and client node 202 corresponds to, forexample, remote VSAT station 123. In yet another embodiment of themulticast system of the present invention, hub node 201 corresponds to,for example, VSAT hub 117, and client node 202 corresponds to, forexample, remote VSAT station 121. Of course, while only a singlesatellite 231 is shown in FIG. 2, it should be understood that system200 could include a plurality of satellites forming the satellitenetwork. Moreover, it should be understood that system 200 could includea plurality of hub nodes 201 connected to one or more telecommunicationsnetworks 104. Further, system 200 can include a plurality of client hubs202.

Hub node 201 includes a Server Content Evaluator and Cache 205 (i.e.,cache 114 in FIGS. 1A and 1B), and a Multicast Engine 206. ServerContent Evaluator and Cache 205 is connected to telecommunicationsnetwork 104 to operatively receive and send communications messagesfrom/to telecommunications network 104 in a well-known manner. ServerMulticast Engine 206 is connected to Server Content Evaluator and Cache205.

Client node 202 includes a Client Multicast Engine 207, a Client ContentCache 208 (i.e., cache 124 in FIGS. 1A and 1B) and a Client ContentSynchronizer 209. Client Multicast Engine 207 is communicatively coupledin a well-known manner to Server Multicast Engine 206 through satellite231. Additionally, Client Multicast Engine 207 is coupled to ClientContent Cache 208. Client Content Synchronizer 209 is communicativelycoupled in a well-known manner to Server Content Evaluator and Cache 205through satellite 231. Client Content Synchronizer 209 is also coupledto Client Content Cache 208, and to at least one client application thatis executing at, for example, a remote station 120 (FIGS. 1A and 1B).

At hub node 202, Server Content Evaluator and Cache 205 evaluates thecontents of unique HTML pages on a real-time basis and marks thoseparticular pages that are capable of being multicast to multipleclients. The same information content can be usually accessed usingmultiple HTTP path names, which are also known as URLs. Server ContentEvaluator and Cache 205 also uniquely identifies each of page havingunique content and that is capable of being multicast using an indexnumber for synchronizing communication between itself and clientapplications. A plurality of the unique base pages and unique objectsassociated with the base pages are stored in the cache portion of ServerContent Evaluator and Cache 205.

Server Multicast Engine 206 is responsible for multicasting any datatogether with the corresponding index numbers identifying the data tothe clients. Server Multicast Engine 206 is capable of sending the datacontents in either a simplex (i.e., no acknowledgment from a client) ora duplex mode (i.e., negative acknowledgments from a client).

Client Multicast Engine 207 receives multicast data and forwardsreceived data to Client Content Cache 208. Client Content Cache 208stores the unique HTML contents of selected pages of information alongwith the corresponding assigned index numbers for the selected pages.

Client Content Synchronizer 209 evaluates requests received from aclient application 210, such as a browser located at a remote station120, communicates with Server Content Evaluator and Cache 205, andderives a specific multicast item that is to be forwarded to clientapplication 210. In the situation that a requested data item, i.e., basepage or object, does not exist in Client Content Cache 208, ServerContent Evaluator and Cache 205 obtains the requested data item fromtelecommunications network 104. Through a multicast mechanism,preferably through satellite 231, Server Content Evaluator and Cache 205forwards the requested data item to Client Content Cache 208. ClientContent Synchronizer 209 also multiplexes multiple client requests andcompresses the requests before forwarding to the Server side 201 of thesystem, thereby providing inbound bandwidth efficiency.

Data flow for the present invention is as follows: A request for aselected data item, such as an HTML page, is received at 220 in FIG. 2by Client Content Synchronizer 209 from a client application locatedwithin a remote station 120. At 221, Client Content Synchronizer 209forwards the request for the data item (in a modified form, ifappropriate) to Server Content Evaluator and Cache 205 through satellite231. When Client Content Synchronizer 209 has received multiple requestsfor HTML data, a received request is preferably multiplexed andcompressed with other requests received by Client Content Synchronizer209, thereby providing inbound bandwidth efficiency at Server ContentEvaluator and Cache 205. Server Content Evaluator and Cache 205 examinesthe content data stored in cache for the requested data item. Amultiplexer portion of Client Content Synchronizer 209 schedulessatellite inbound responses to the requests, thereby synchronizingbandwidth utilization.

When the requested data item is not stored in cache at hub node 201,Server Content Evaluator and Cache 205 requests the information fromtelecommunications network 104 in a well-known manner at 222, such asusing a standard HTML request. The requested data item is returned at223, preferably in the form of a standard HTML response, either directlyor redirected automatically from telecommunications network 104. At 224,Server Content Evaluator and Cache 205 identifies the received responseusing a unique index number, and forwards the received response toServer Multicast Engine 206. At 225, Server Content Evaluator and Cache205 sends the index number corresponding to the requested data item. At226, Server Multicast Engine 206 multicasts the requested data item andthe corresponding index number for the requested data item to ClientMulticast Engine 207. At 227, all multicast contents received by ClientMulticast Engine 207 are forwarded to and saved by Client Content Cache208. At 228, Client Content Synchronizer 209 requests the content of therequested data item from Client Content Cache 208 using the indexidentifier received from Server Content Evaluator and Cache 205. At 229,Client Content Cache 208 returns the content of the requested data itemto Client Content Synchronizer 209. At 230, Client Content Synchronizerforwards the content of the requested data item to the requesting clientapplication.

When the requested data item is found to be stored in cache at hub node201, Server Content Evaluator and Cache 205 sends a message to ClientContent Synchronizer 209 at 225 indicating the index number for therequested data item stored in Client Content Cache 208. At 228, ClientContent Synchronizer 209 requests the content of the requested data itemfrom Client Content Cache 208 using the index identifier received fromServer Content Evaluator and Cache 205. At 229, Client Content Cache 208returns the content of the requested data item to Client ContentSynchronizer 209. At 230, Client Content Synchronizer forwards thecontent of the requested data item to the requesting client application.

FIG. 3 is a schematic block diagram of a portion of broadbandcommunications network 100 (FIGS. 1A and 1B) that provides a pageaccelerating system 300 according to the present invention. Forsimplicity, FIG. 3 shows only the functional blocks of the pageaccelerating system of the present invention. Page accelerator system300 includes a hub or server node portion 301 and at least one clientnode portion 302. Hub node portion 301 is connected totelecommunications network 104 (FIGS. 1A and 1B), again, such as theInternet (WWW). Alternatively, telecommunications network 104 can alsobe a local area network (LAN) or a wide area network (WAN) that, inturn, is connected to the Internet. Once again, telecommunicationsnetwork 104 includes information that is preferably stored in the formof hypertext mark-up language (HTML) pages. Hub node portion 301 iscommunicatively coupled to each client node portion 302 over a satellitecommunication link utilizing a satellite 313 of a satellite network in awell-known manner.

In one embodiment of the page accelerator system of the presentinvention, hub node portion 301 is located at, for example, VSAT hub117, and client node portion 302 is located at, for example, VSAT hub128. In another embodiment of the accelerator system of the presentinvention, hub node portion 301 is located at, for example, VSAT hub117, and client node portion 302 is located at, for example, remote VSATstation 123. In yet another embodiment of the page accelerator systemmulticast system of the present invention, hub node 201 corresponds to,for example, VSAT hub 117, and client node 202 corresponds to, forexample, remote VSAT station 121. Of course, while only a singlesatellite 313 is shown in FIG. 3, it should be understood that system300 could include a plurality of satellites forming the satellitenetwork. Moreover, it should be understood that system 300 could includea plurality of hub node portions 301 connected to one or moretelecommunications networks 104. Further, system 300 can include aplurality of client hub portions 302.

Hub node portion 301 includes a Hub Tunnel Agent 303 (also referred toherein as Hub Page Acceleration Sub-system (HPAS)), a VSAT Hub 304 and acentral satellite dish antenna 305. Hub Tunnel Agent 303 is connected totelecommunications network 104 to operatively receive and sendcommunications messages from/to telecommunications network 104 in awell-known manner. Hub Tunnel Agent 303 is connected to VSAT Hub 304,and VSAT hub 304, in turn, is connected to central satellite dishantenna 305.

According to one exemplary embodiment of the present invention, a clienthub portion 302 includes a personal computer 306 (also referred toherein as a Remote Web Browser (RWB)), a Remote Tunnel Agent (RTA) 307(also referred to herein as a Remote Page Acceleration Sub-system(RPAS)), a VSAT 308 and a remote satellite dish antenna 309. Thisexemplary embodiment corresponds to PC 122 and remote VSAT station 123shown in FIGS. 1A and 1B. According to another exemplary embodiment ofthe present invention, a client hub portion 302 includes a PC-VSAT-RTA310 having an integrated RTA and an RWB, and a remote satellite dishantenna 311. This second exemplary embodiment corresponds to PC-VSAT 121shown in FIGS. 1A and 1B.

VSAT 308 and PC-VSAT-RTA 310 communicate with VSAT Hub 304 via remotesatellite dish antennas 309 and 311, respectively, satellite 313, andcentral satellite dish antenna 305. VSAT Hub 305 connects totelecommunications network 104 (i.e., the Internet) via HTA 303, andallows a user to perform activities on the Internet, such as Internetbrowsing, using the hypertext transfer protocol (HTTP).

Page accelerator system 300 of the present invention provides twobenefits. First, the requirement that a TCP connection be establishedover the satellite link between the client on a PC 306 (or a PC-VSAT-RTA310), i.e., the user's remote web browser or RWB, and a desired webserver within the Internet is eliminated. Second, page acceleratorsystem 300 provides the necessary hardware for page acceleratorsoftware.

As previously described, before an RWB can send an HTTP GET request fora page, a connection between the RWB and the appropriate web server isestablished. When the web page contains objects from different webservers (as is very common for advertisements and for web server loaddistribution), at least one connection will be established to eachdifferent web server, each of which can take over 600 ms by satellite.By using RTA 307 at VSAT 308 and a HTA 303 at VSAT Hub 304, however, amajority of all connections can be made locally with the relevant RTAand HTA. That is, the RWB in remote PC 306 is connected to RTA 305 atthe remote VSAT location, and the web server located within the Internet(telecommunications network 104) is connected to HTA 303 at VSAT Hub304. Sub-systems 303 and 307 then maintain a permanent connection (i.e.,persistent connection) between each other that carries all the trafficbetween PC 306 and the desired web server.

FIG. 4 shows a simplified data flow diagram for a web page accessfunction for a VSAT network having a page accelerator system accordingto the present invention. As shown in FIG. 4, only application data issent over the satellite link (assuming a TCP acceleration mechanism isused). In the absence of TCP acceleration, TCP acknowledgements are sentover the satellite link as well. Overhead traffic, such as TCP start andstop commands, are eliminated from the satellite link (with or withoutacceleration), thereby reducing the total response time and savingresources.

As shown in FIG. 4, access to a web page in a page accelerator systembegins when an RWB in PC 306 establishes a connection with RTA 307 withData Exchange 401. Because PC 306 “knows” the location of RTA 307, thereis no need for PC 306 to make a DNS request. As with a true connectionto the Internet, data exchange 410 requires at least threecommunications between PC 306 and RTA 307 for synchronization andacknowledgement of the connection.

After the connection is made between PC 306 and RTA 307, the RWB in, forexample, PC 306 requests a desired web page using an HTML GET request atData Exchange 402. The GET request is sent via RTA 307 to HTA 303.

HTA 303 then makes an initial DNS request for an IP address, andreceives the requested IP address from the appropriate DNS server atData Exchange 403. After the IP address is obtained, HTA 303 establishesa connection using the proper IP address at Data Exchange 404. Both dataexchanges 403 and 404 are performed locally between HTA 303 and thedesired web server within the Internet (telecommunications network 104).Consequently, any delay that would be experienced through satellite 313is avoided.

After a connection is established to the desired web server, HTA 303requests the desired web page using an HTML GET request (Data Exchange405), and the relevant HTML base page is sent to PC 306 by the webserver (Data Exchange 406). As of this point, the only two satellitedelays experienced have been for the HTML GET request (Data Exchange402) and the HTML base page (Data Exchange 406).

When the HTML base page is received by PC 306, the RWB in PC 306 beginsto request the individual objects associated with the received HTML basepage, and the web server sends the objects to PC 306 (Data Exchange407). Data Exchange 407 is repeated as many times as necessary forretrieving all of the objects associated with the received HTML basepage.

In one embodiment of the present invention, PC 306 requests the objectsindividually and, consequently, experiences a satellite delay for eachrequest and transfer (i.e., for each Data Exchange 407). Because anaverage web HTML base page can contain 10 or 20 objects, a large delaycan be experienced as each object is retrieved.

When all of the objects have been retrieved, RTA 303 and HTA 307 closetheir respective connections the web server within the Internet(telecommunications network 104) and with PC 306 through a series offinish and acknowledge communications (Data Exchange 408 and 409,respectively). Because Data Exchanges 408 and 409 are performed locally,no additional satellite delay is incurred.

According to another embodiment of the present invention, an objectpre-fetching mechanism further reduces the processing time for the webrequests. The object accelerating mechanism extends the functionality ofsystem 300 by significantly reducing the inbound traffic, i.e., thetraffic between VSAT Hub 204 and VSAT 306/PC-VSAT-RTA 310.

At hub node 301, a hub object pre-fetch module 312 is incorporated intoHTA 303 for facilitating communication with the Internet(telecommunications network 104). All packets pass through hub objectpre-fetching module 312. When an HTTP GET request arrives at VSAT Hub304 from, for example, PC 306, VSAT Hub 304 forwards the GET request tothe appropriate web server within the Internet (telecommunicationsnetwork 104). When the request contains a cookie (i.e., pre-configuredinformation relating the user that is usually saved in the remotemachine), the cookie is also saved in VSAT Hub 304. When an HTML basepage is delivered as a response from the Internet (telecommunicationsnetwork 104) to VSAT Hub 304 via HTA 303, the HTML base page is saved ina hub memory within VSAT Hub 304, as well as forwarded to the relevantVSAT 308 via satellite 313.

HTA 303 then processes the HTML base page and begins requestingindependent objects of the base page, i.e., the objects that do notinteract with the web browser. Potentially dynamic objects that interactwith web browsers, such as JAVA scripts and Microsoft Excel files, arehandled separately, as will be explained below. After HTA 303 receivesthe independent objects, HTA 303 forwards the independent objects to therelevant RTA 307. When the original HTML GET request contains a cookie,all further requests from HTA 303 for HTML pages related to the cookiepreferably contain the cookie, as well, for efficiently processing theobject retrieval. When dynamic HTML files (i.e., written in JAVA script)are received by HTA 303, the dynamic HTML files are compiled (similar tothe process that would be performed by the RWB) for providing “page” or“object” links. The objects are then retrieved by HTA 303 and forwardedto RTA 307. Microsoft Excel files are compressed by HTA 303 usingexisting compression schemes, forwarded, and decompressed by RTA 307before forwarding to the RWB in PC 306.

At the remote end, an object storage module is installed within RTA 307.When an HTML base page is delivered from VSAT Hub 304, RTA 307 keeps acopy of the base page and forwards the base page to the RWB in PC 306.All of the objects that arrive from VSAT Hub 304 are also stored at RTA308. When the RWB in PC 306 begins to parse the received HTML base page,the RWB sends requests to RTA 307 for all objects and, when found storedin RTA 307, does not contact the web server directly.

Even with the object pre-fetching mechanism of the present invention,the RWB at PC 306 may wait for a significant amount of time to receive arequested HTML base page (600 ms and the variable Internet delay).Consequently, the prefetching mechanism of the present invention canpre-fetch several base pages to RTA 307 that the RWB in PC 306 is mostlikely to request. RWBs have the capability for defining a “home page”,or a web site that a user always accesses while using the Internet. RTA307 identifies the home page and maintains an updated version of thebase page corresponding to the home page stored in memory. Additionally,the HTA maintains a list of “favorite” pages (popular web sites), andmaintains updated versions of the base pages for the favorite sites.According to the invention, the home and favorite web pages areperiodically sent from HTA 303 to all RTAs (i.e., RTA 307 andPC-VSAT-RTA 310) using multicast techniques. An RTA, when receiving thefavorite base pages, saves favorite base pages in memory as well. Thisembodiment of the pre-fetching mechanism of the present invention isreferred to as “multicasting pre-fetched base pages”.

When, for example, the RWB in PC 306 requests a home page or a favoritepage that is already stored in the memory of RTA 307, the requested HTMLbase page is immediately forwarded to the RWB from RTA 307. Inconjunction, as with the “pre-fetch” process, the request for the pageis also forwarded to HTA 303, and is processed so that objects that areassociated with the requested page are updated as described above.

FIG. 5 shows a simplified data flow diagram for a web page accessfunction for a VSAT network having a page acceleration system that usesobject pre-fetching according to the present invention. As shown in FIG.5, access to a web page by a page accelerator system having apre-fetching mechanism according to the present invention begins whenthe RWB in, for example, PC 306 establishes a connection with RTA 307 atData Exchange 501. As previously described, because PC 306 “knows” thelocation of RTA 307, there is no need for PC 306 to make a DNS request.

After the connection is made between PC 306 and RTA 307, the RWB in PC306 requests a desired web page using an HTML GET request (Data Exchange502). The GET request is sent to HTA 303 via RTA 307. When the HTML basepage corresponding to the requested web page has already been providedto RTA 307 through the multicast pre-fetched base page mechanism of thepresent invention, the HTML base page is immediately forwarded from RTA307 to the RWB in PC 306 at Data Exchange 503.

At Data Exchange 504, HTA 303 makes an initial DNS request for an IPaddress, and receives the IP address from the web server. After the IPaddress is obtained from the DNS server, HTA 303 establishes aconnection with the proper IP address at Data Exchange 505. After aconnection is established, HTA 303 requests the desired web page usingan HTML GET request at Data Exchange 506, and the relevant HTML basepage is sent to PC 306 by the web server via HTA 303 and RTA 307 at DataExchange 507.

As soon as HTA 303 receives the requested HTML base page, at DataExchange 508 HTA 303 requests the individual objects associated with theHTML base page from the Web. As each object is received, the object isimmediately forwarded to RTA 307 for storage at Data Exchange 509. Thisstep is repeated as many times as necessary for retrieving all of theobjects associated with the requested HTML base page.

The RWB in PC 306, upon receiving the requested HTML base page, alsobegins to request the individual objects associated with the HTML basepage (Data Exchange 510). This request, however, is local and is madeonly to RTA 307. RTA 307, in turn, determines whether the requestedobjects have previously been received from HTA 303. If so, RTA 307forwards the requested objects to the RWB in PC 306 at Data Exchange51). When the requested objects have not been previously received by RTA307, and when RTA 307 determines that the requested objects are to bepre-fetched and forwarded by HTA 303, the RWB requests are locallystored by RTA 307 for a predetermined amount of time while RTA 307 iswaiting to receive the corresponding objects from HTA 307.

In some cases, however, it can be necessary for the RWB in PC 306 tocommunicate directly with a web server using, for example, encrypted GETrequests. In such a situation, the RWB in PC 306 sends an object requestdirectly to the web server at Data Exchange 512, and the web serverforwards the requested object back to the RWB in PC 306 at Data Exchange513. After such a communication sequence, however, PC 306 returns tocommunicating with RTA 307 for normal cases.

Of course, the steps of object retrieval, whether direct or through RTA307, are repeated by PC 306 as many times as necessary for retrievingall of the objects associated with the requested HTML base page. Becausea majority of the requests made by the RWB in PC 306, however, are madelocally to RTA 307, there is a minimum satellite delay experiencedduring the process, significantly reducing the time required for webpages to fully load.

Once all of the objects are retrieved, HTA 303 and RTA 307 close theirrespective connections with the web server within the Internet(telecommunications network 104) and the RWB in PC 306 through a seriesof finish and acknowledge communications (Data Exchanges 514 and 515,respectively). Because Data Exchanges 514 and 515 are each performedlocally, the data exchanges do not result in any additional satellitedelay.

FIG. 6 shows a flow diagram of a process performed when, for example,RTA 307 receives an HTTP GET request from the RWB in PC 306 (Step 601).At step 602, RTA 307 determines whether the HTTP GET request is arequest for an HTML base page. If so, flow continues to step 603, whereRTA 307 verifies whether a copy of the requested base page is stored inthe memory of RTA 307. If, at step 603, RTA 307 determines that therequested base page is stored in the memory of RTA 307, flow continuesto step 604 where RTA 307 forwards the base page to PC 306. Flowcontinues to step 605, where RTA 307 forwards the request to VSAT Hub304. If, at step 603, RTA 307 determines that the requested base page isnot stored in the memory of RTA 307, flow continues to step 605.

If, at step 602, RTA 307 determines that the GET request is not for anHTML file, flow continues to step 606, where RTA 307 determines whetherthe GET request is for an object that is to be prefetched. When theobject is not a prefetched object, flow continues to step 605, where RTA307 forwards the request to VSAT Hub 304. If, at step 606, RTA 307determines that the requested object is a “prefetched” object, flowcontinues to step 607 where RTA 307 determines whether RTA 307 hasalready received the object from HTA 303. If so, flow continues to step608, where RTA 307 sends the object to PC 306. If, at step 607, RTA 307determines that the object has not yet been received from HTA 303, flowcontinues to step 609 where RTA 307 waits a predetermined period oftime.

Upon expiration of the predetermined period of time, flow continues tostep 610 where RTA 307 determines whether the object has been received.If so, flow continues to step 608, where RTA 307 sends the object to PC306. If not, flow continues to step 605 where RTA 306 forwards theobject request to VSAT Hub 304.

Table 1 shows a comparison between access time for a conventional VSATnetwork, for a VSAT network with a persistent connection without objectpre-fetching (FIG. 4), and for a VSAT network having a complete pageacceleration system according to the present invention (FIG. 5). Inmaking the comparisons, the following assumptions have been made forsimplifying the analysis.

The response time of a web server from the time VSAT Hub 304 makes arequest to when the request is answered is assumed to be 100 ms. Thesatellite delay for passing requests and objects between hub antenna 305and remote antenna 309 through satellite 313 is assumed to be 500 ms.The transmission time of a GET request over satellite 313 is assumed tobe 60 ms. The same GET request has a transmission time of less than 5 msbetween VSAT hub 304 and the web server within the Internet(telecommunications network 104). As a result, the delay experiencedbetween VSAT hub 304 and the web server will be neglected and treated aszero. The transmission time of an object is assumed to be 40 ms.

It is assumed that the web browser opens two connections to every webserver for retrieving the page objects. It is also assumed that webpages with up to 10 objects reside on a single server. For more complexpages, it is assumed that the HTML for the requested page resides on oneserver and all the objects reside on a different server. All objects areassumed to be simple, i.e., they can be pre-fetched. The TCP connectionestablishment delay over the LAN at the remote VSAT is negligible and isassumed to be zero. A connection establishment delay at the hub side isassumed to be 20 ms. A DNS server response time is assumed to be 25 ms.

These assumptions do not take into account the uncertainty of Internetdelays, web browser behavior, and web page design. Because such delayscan occur regardless of whether there is a page acceleration system,they have been disregarded.

TABLE 1 A COMPARISON OF WEB ACCESS TIMES Conventional Page AccelerationVSAT System without Pre-fetch Page Acceleration No. of No. No. withPre-Fetch Objects Seconds Requests Seconds Request Seconds No. Request 12.6 7 1.5 2 0.9 1 10 6.1 20 5 11 1.6 1 20 10.8 36 8.5 21 2.4 1

The ‘Seconds’ in Table 1 refers to the expected amount of time for a webpage having the indicated number of objects to load. The ‘No Requests’columns refer to the expected number of requests that may be sent tofully load the desired web page from the Web Browser (RWB) to the WebServer in the Internet.

As shown in Table 1, the access time for a Page Acceleration systemwithout pre-fetching is reduced in comparison to a conventional VSATsystem, and the access time is significantly reduced when the PageAcceleration system uses a pre-fetch process.

Although the descriptions above refer to communications between VSAT hub304 and PC 306 via remote VSAT 308 and RTA 307, such communicationscould also be between VSAT hub 304 and PC-VSAT-RTA 310, their operationwould be the same, as would the results of Table 1.

Secure Network Protocol Acceleration

Aspects of the present invention include page acceleration over a secureconnection, such as one using a secure sockets layer, for example. Anexemplary embodiment of the present invention involves acceleration ofsecure communications between a web browser, operating on a computer anda web site using secure protocol operating over a lower level layer suchas a TCP/IP layer, transmitted over a satellite communication system.Another exemplary embodiment involves secure certificate generation andhandling.

Secure communications acceleration may be accomplished using a remoteterminal coupled to a computer. The remote terminal may interceptsignals intended for the web server and may generate secure protocolspecific data to simulate the responses of a web server that wouldordinarily be transmitted to the computer in accordance with a secureprotocol, such as SSL for example. The secure protocol, acceleratedusing generated certificates, may enable the remote terminal to convertdata into a format for transmission through the satellite communicationssystem, and eventually to the web server, while maintaining the secureprotocol connection with the computer. A secure protocol exchange mayalso occur between the web server and a hub, or other similar device incommunication with the web server and the satellite communicationssystem. The hub may also maintain a connection with the web server bygenerating signals indicating that the signals were forwarded from thecomputer, and may intercept signals transmitted by the web serverintended for the computer. The hub may receive data forwarded from thedestination terminal through the satellite communication system, mayconvert the data into the secure protocol format and may forwardnecessary data to the web server. Accordingly, an embodiment of theinvention enables a web browser operating on a computer to communicatesecurely using a secure protocol, such as the SSL protocol, operatingover a TCP/IP layer through a satellite communication system with anacceptable amount of delay.

An embodiment of the present invention may relate to the encryption ofdata above the transport level, e.g., at the application layer. In anSSL environment, for example, handshaking may be required to exchangesecure pages. The number of handshakes required for exchange of eachimage in an SSL secured page, for example, is dependent upon, amongother things, the type of encryption selected by the client and/orserver, or whether the client and server both require authenticationduring the transfer. For example, in typical applications in which fullhandshaking is performed, for each image in a page there is between fourand eight handshaking exchanges required to establish a SSL connection.Where there are, for example, eight exchanges required, the delay overthe satellite could be as much as four seconds of additional transfertime for each image in an SSL encrypted page. Where there are 20 images,the net delay may add 40 seconds to the transfer of a page on an SSLsecure link. Accordingly, a substantial need arises for accelerating thesecure HTTP link.

The 40 second delay previously described in the illustrative embodimentis calculated assuming the use of nonsimultaneous sessions. Where thereare a number of simultaneous connections, the maximum delay time may bereduced accordingly. For example, where the default value for thebrowser establishes two simultaneous connections, the transfer timewould be reduced to 20 seconds. As the number of connections at thebrowser increase, another problem arises. With the increase in thenumber of connections, the number of handshakes required to setup thetotal number of connections increases by a factor corresponding to thenumber of connections. Thus, by increasing the number of connections,each new page may increase the number of handshakes. Unfortunately, areduction in the delay resulting from the increase in the number ofconnections in the browsers may be offset by increased handshaking. Inaddition, increasing the number of connections substantially increasesthe resource utilization of the ISP provider, including the satellitenetwork provider. Therefore, a new technique is required to acceleratethe pages.

Embodiments of the invention may utilize an increase number ofconnections, but such embodiments involve an improvement upon the use ofa greater number of connections. For example, in some exemplaryembodiments it may be helpful to have the hub server monitor and countthe number of connections for each individual remote terminal and limitthe number of connections that the remote terminal may utilize. As aresult, the system may conserve bandwidth and may also prevent a singleremote terminal from monopolizing the bandwidth associated with aparticular hub.

Embodiments of the present invention may utilize a single tunnel betweenthe remote terminal device and the hub. In these embodiments secureprotocol acceleration may utilize the existing page accelerationtechniques and may sit on top of the existing acceleration and pageacceleration protocols.

Specifically, in an embodiment of the invention, secure communicationacceleration over a satellite network may involve the handshakeacknowledgements between a browser and a web server. To that end, aremotely located secure protocol accelerator (“remote protocolaccelerator” or “RPA”) may be configured as a proxy server incommunication with the browser, as a software module implemented as adriver in the personal computer, or be incorporated into a modem, forexample, transparent to the personal computer. A hub page accelerator(“HPA”) is typically located at the hub, the proxy server located at thehub, or the web server.

Signals from the computer on which an Internet browser may be operatingmay be redirected to the RPA as a proxy server. An HTTPS connection istypically initiated via a HTTP “CONNECT” message sent from the browserto the proxy server, the remote page accelerator in this case. TheCONNECT message is specific to secure HTTP in that only when a secureHTTP (or HTTPS) connection is formulated does the message transmit fromthe browser to the RPA proxy server. In accordance with aspects of thepresent invention, the proxy server may implement remote pageacceleration.

In standard HTTPS communications, employing applications running onTCP/IP, for example, the CONNECT message might be passed directly to theproxy server located in the hub equipment. However, when SSLacceleration is employed, the CONNECT message sent from the browser maybe intercepted by the remote page accelerator and an “OK” packet may bereturned to the browser, which may be sent directly from the remote pageaccelerator. The browser may next initiate a SSL handshake connection bysending a “HELLO” message to the web server, which may also beintercepted by the RPA. The handshake connection between the browser andthe RPA may be a standard SSL connection continues and may include allof the standard SSL handshaking.

The RPA may have its own public key and private key, which may begenerated on the fly, and keys may be assigned for every remoteterminal. In accordance with further aspects of the invention, eachindividual RPA may be configured to be a certificate generator. In thismanner, each RPA may dynamically generate its own public and privatekeys. Such key generation may be performed either initially or as eachsession is started. Thus, the RPA may generate and exchange the securekeys with the browser, so that both may generate a master secret key.Packets of data may then be transmitted from the RPA to the HPA over thesatellite communication system.

At the web server side of the communication, the HPA may proceed tosetup a secure connection with the web server as follows. The standardSSL handshake protocol includes the transmission of initial handshakingsignals including a CONNECT signal. Additional signals may be exchangedbetween the HPA and the web server, being transmitted transparentlythrough the proxy. These messages may include, for example, the “OK”,client “HELLO”, server “HELLO/certificate”, premaster secret, exchangeof master secret keys and finally, the GET command. The master secretkey between the HPA and the web server may be established in theconnection between the HPA and the web server, and may be a differentmaster secret key from that established by the browser and the RPA.Thereafter, all GET commands and/or other messages from the browserand/or the web server in the link between the HPA and the web server maybe encrypted using this master secret key. Over the newly establishedSSL connection, between the HPA and the web server, standard HTTPS datamay be exchanged in a normal fashion.

In this manner, the handshake protocols necessary for generating, forexample, the master secret keys and/or other encryption keys between theHPA and web server can be exchanged at a high rate of speed, and thetunneling across the satellite connection and/or other wirelessconnection between the HPA and RPA is minimized. As a result, theoverall connection time for establishing a secure connection between thebrowser and the web server, across the satellite network, may besubstantially accelerated.

In addition to the secure protocol acceleration just described, the pageacceleration discussed in the application incorporated by reference,patent application Ser. No. 09/781,554 entitled System and Method ForInternet Page Acceleration Including Multicast Transmission, filed Feb.13, 2001, may be used to accelerate secure page transfers across thesatellite link by assembling a series of request acknowledge portions atthe hub page accelerator and then transferring those pages in bulkacross the HPA/RPA link tunnel connection to the browser in the mannerdescribed in the previous application.

To summarize one aspect of the invention, transmissions from the webserver to the browser may be initially transmitted across secureconnections between the HPA and the web server, and may passtransparently through a proxy server. At the HPA, the HTTPS data may bedecrypted using a set of keys and then may be transferred from the HPAto the RPA using the standard encrypted tunnel across the satellitenetwork. Once at the RPA, the data may then be re-encrypted using theset of keys of the RPA and may be transmitted to the browser usingstandard SSL protocols, for example.

In the hub, components of the page may be assembled by the hub pageaccelerator in varying degrees. In one embodiment, as each image may bedownloaded and acknowledged from the hub page accelerator and/or proxyserver in the hub, the image may immediately be transmitted to the RPAand forwarded to the browser. In alternative embodiments, a series ofimages may be queued in the HPA and then forwarded to the RPA across thetunnel. Once the original master session is established between the HPAand the web server, as additional web pages and/or images are accessedfrom the browser to the web server, additional handshaking may occurbefore each image and/or web page may be transmitted. Typically, thishandshaking may be less complex than the initial setup handshaking,nevertheless it may still require as many as eight transmissions betweenthe HPA and the web server and between the browser and the RPA.

A substantial reduction in the amount of delay experience by the usermay be achieved in the above mentioned environment employing aspects ofthis invention. With respect to the page acceleration disclosed in theapplication incorporated by reference, since the secure protocolcommunication may be decrypted at the HPA using the master secret key,it is possible to parse the request for pages at the HPA and request allobjects immediately from the server using multiple connections. As aresult, the pages, and all of the images located within those pages, maybe returned at a substantially higher rate than would normally berealized without page acceleration.

The returned data includes a web page, which may specify each of theimages and/or other objects contained in that web page. Through parsing,these images and/or objects may be preferably pre-fetched in the HPAserver, however, in certain circumstances, such as if the HPA isintegrated with the proxy, for example, the images may be pre-fetchedand cashed in a proxy server for transfer to the RPA. As a result, theimages may be made immediately available at the proxy server forforwarding to the browser, and may also be pre-fetched in the RPA forimmediate transmission to the browser once the request from the browseris initiated. Thus, the perceived speed of the communication experiencedby the user may be substantially improved. Therefore, depending on theconfiguration of the web server, the reduction in latency time can besignificant.

Some embodiments of the present invention overcome the insufficienciesassociated with proxy servers which do implement a pre-fetch, in thatsuch servers cannot effectively pre-fetch during a secure connectionbecause the transmission from the server is encrypted. A substantialadvantage attributable to some embodiments of the present invention isthat it allows pre-fetching even in connections involving secureprotocols through the use of the HPA. Embodiments of this invention maybe expanded to use in pre-fetch servers such that, for example, theproxy and pre-fetch server may be integrated into the HPA. Thus,communications using pre-fetching servers may now be expanded to includeall secure protocol connections. This is a substantial improvement overthe current state of the art.

An additional advantage of some embodiments of the present configurationis that the close connection message may be intercepted by the HPA suchthat it may not necessarily passed to the browser. Thus, the secureprotocol close connection signal may be intercepted and responded to bythe HPA, and the communication may be re-open in a manner transparent tothe browser. In the event that the connection is to be terminated, theRPA then terminates the secure protocol connection with the browser atthe end of the secure session.

Referring to the accompanying figures, an exemplary embodiment depictinga conventional SSL connection is described in FIG. 7A as the directservice connection between the browser 712 and the web server 716. Tocompensate for delay that results when such connections are establishedover a satellite communications system, referring to FIG. 7B, theconnection is broken down into secure links A1, A2, and A3.Representative Link A1 links the remote web browser 712 with the pageaccelerator 713. Link A2 represents the satellite communication oversatellite 725. Link A3 represents the connection between the hub pageaccelerator 705 and web server 716. Of course, various combinations ofcomponents can be utilized to communicate over the links in a variety ofmanners. Link A2 may provide an encrypted link using a conventionalsatellite encryption technique. Accordingly, secure protocolacceleration need occur only on links A1 and A3 for which the terminalsintercept data specific to the secure transmission and transmit thecontent of the secure transmission. The particular protocol foracceleration a secure connection on links A1 and A3 is described, usingan SSL communication as merely an example, in exemplary embodimentsillustrated in FIG. 8.

Again referring to FIG. 7B, SSL authentication, for example, on link A1may be conducted by Spacenet, the encryption on link A2 may also handledby Spacenet, and the SSL authentication, for example, on link A3 mayalso be performed using standard SSL protocols between the Spacenet huband the web server. Thus, each link in the connection may be secured. Toestablish and/or during communication, the remote browser 712 at thecomputer may receive appropriate signals to suggest that the browser hasestablished a secure connection with the web site of interest, as isdiscussed in more detail below.

FIG. 8 is a schematic block diagram of a portion of broadbandcommunications network 100 (FIGS. 1A and 1B) that provides a pageaccelerating system 800 according to the present invention, similar tothe diagram of FIG. 3 above. For simplicity, FIG. 8 shows only thefunctional blocks of the secure page accelerating system of a preferredembodiment of the present invention. For purposes of clarity, theindividual components have been indicated using similar referencenumerals. The individual components of a preferred embodiment forperforming acceleration of a system communicating over secure networkfollows.

Page accelerator system 800 may include a hub node portion 801 and atleast one client node portion 802 for performing web browsing and thelike. Hub node portion 801 may be connected to a web host 816 orInternet computer 817, or such similar devices, including accessible webpages associated with various web sites. The connection of hub 804 tothe web site of interest may be established through telecommunicationsnetwork 104 (FIGS. 1A and 1B), again, such as the Internet (“WWW”),including a web server. Alternatively, telecommunications network 104may consist of a local area network (LAN) or a wide area network (WAN)that, in turn, is connected to the Internet. Once again, network 104 mayinclude information that is preferably stored in the form of web pages.Hub node portion 801 may be communicatively coupled to each client nodeportion 802 over a satellite communication link utilizing a satellite825 of a satellite network in a well-known manner.

Hub node portion 801 may include a Hub Tunnel Agent 803 (also referredto herein as Hub Page Accelerator (HPA)), a VSAT Hub 804 (hub) and acentral satellite dish antenna 805. HPA 803 may be connected totelecommunications network 104 to operatively receive and sendcommunications messages from/to telecommunications network 104 in awell-known manner. HPA 803 may be connected to VSAT Hub 804, and VSATHub 804, in turn, may be connected to central satellite dish antenna805.

According to one exemplary embodiment of the present invention, a clienthub portion 802(a) may include a personal computer 806 (also referred toherein as computer) operating Remote Web Browser (RWB)), a Remote TunnelAgent (RTA) 807 (also referred to herein as a Remote Page Accelerator(RPA)), a VSAT 808 and a remote satellite dish antenna 809. Thisexemplary embodiment corresponds to PC 122 and remote VSAT station 123shown in FIGS. 1A and 1B. According to another exemplary embodiment ofthe present invention, a client hub portion 802(b) may include aPC-VSAT-HPA 810 having an integrated RTA and an RWB, and a remotesatellite dish antenna 811. This second exemplary embodiment correspondsto PC-VSAT 121 shown in FIGS. 1A and 1B. In yet a further embodiment, aclient hub portion 802(c) may include a Remote Web Browser 812, and aVSAT incorporating a Remote Page Accelerator 813. Of course, anycombination of the identified components, or similar components, may beadapted for use in the client hub portion 802 consistent with thedisclosed invention.

VSAT 808, PC-VSAT-RPA 810, and VSAT-RPA 812 may communicate with VSATHub 804 via remote satellite dish antennas 809 and 811, 814,respectively, satellite 813, and central satellite dish antenna 805.VSAT Hub 805 may connect to telecommunications network 104 (i.e., theInternet) via HPA 803, and may allow a user to perform activities on theInternet, such as Internet browsing, using the hypertext transferprotocol (HTTP).

As previously described, a computer can send an HTTP GET request for apage by establishing a connection between the computer and theappropriate web server. That is, for example, the web browser in remotePC 806 may be connected to RTA 805 at the remote VSAT location, and theweb server located within the Internet (telecommunications network 104)may be connected to HPA 803 at VSAT Hub 804. Sub-systems 803 and 807 maythen maintain a permanent connection (i.e., persistent connection) thatcarries all the traffic between PC 806 and the desired web server.

As described with respect to the embodiment illustrated in FIG. 3, inembodiments of the page accelerator system of the present invention, hubnode portion 801 and client node portion 802 may be arranged using anynumber of configurations and placed in a variety of locations consistentwith the scope of the invention. Of course, while only a singlesatellite 813 has been illustrated in FIG. 8, it should be understoodthat system 800 may include a plurality of satellites forming thesatellite network. Moreover, it should be understood that system 800 mayinclude a plurality of hub node portions 801 connected to one or moretelecommunications networks 104. Further, system 800 may include aplurality of client hub portions 802.

FIG. 9 depicts a preferred embodiment for performing secure protocolacceleration; establishing a secure connection between a computeroperating a web browser and a web site of interest over a satellitecommunication system; and use of the satellite communication system in amanner transparent to both the browser and the web site of interest.This technique may be accomplished by mimicking the secure protocoldata, SSL data in this example, and transmitting signals to the computerand the web server to simulate a typical secure communication.

Specifically, in the exemplary embodiment of FIG. 9, the inventionillustrated may establish a secure link using the HTTP protocol over aSSL layer or other HTTPS layer. In the first step of the protocol, thebrowser may attempt to establish a connection with the web server usinga standard HTTPS “CONNECT” command. The “CONNECT” command may beintercepted by the RPA, or similar remote terminal, and an “OK” signalmay be transmitted by the RPA to the browser. The browser may nexttransmit a client “HELLO” command which may be intercepted by the RPA.In response, a web server “HELLO” may be generated by the RPA andtransmitted to the browser.

Establishment of an SSL communication may further require transmissionof a server certificate by the web server to the browser, typicallytransmitted in the server “HELLO” signal. In accordance with SSLprotocol, the certificate typically contains the server's public key,the dates for which the certificate is valid, the certificate's serialnumber, the server's host name, the Certification Authority's (CA)domain name, and the Certification Authority's signature, and may omitor include additional features including extensions. In this embodiment,such a certificate may be verified by the browser in a verification stepbefore additional communications will be authorized. In embodiments ofthe invention, certificates created under the apparent authority of theCertificate Authority (“CA”) may be produced and provided locally by thebrowser, satellite modem or hub, for example. For example, SSL uses X509certificates.

Upon receipt, the browser may check the certificate to determine whetherthe certificate has expired. The host name listed on the certificate asthat of the web server may be reviewed to determine if it matches thehost name of the web site of interest. The browser also determines ifthe CA, used to sign the certificate, is one previously identified bythe browser as a trusted CA. The browser may verify the CA's signatureusing the public key. Additional steps may also be performed, beyondthose required by the secure protocol, including steps to verify thatthe host name of the CA matches that indicated on the certificate. Oncethe verification process for verifying the identity of the web serverhas been successfully completed, the public key from the RPA in theserver “HELLO” may be utilized by the browser to generate a securesession between the browser and the RPA. Should the web server require acertificate from the browser, such requests may be forwarded to thebrowser and an additional validation process, including an exchange ofinformation, may be carried out with the browser by the RPA, whichwould, validate the communication with the browser.

In the handshaking steps that may follow the initial server verificationstep, there may be an exchange of information between the browser andthe web server, via the RPA. For example, through signals transmittedbetween the browser and the server, the browser may provide a list ofavailable cipher schemes, from which the web server selects a desiredcipher scheme and transmits to the browser an indication of thatselection. Also, as illustrated using previously received information,the browser may generate and transmit a premaster secret key (PMS).Through the exchange of such information and the premaster secret key,the browser and RPA may establish a symmetric master secret (MS) keywhich may be resident both at the browser and the RPA, illustrated inFIG. 9 as MS.sub.1. The master secret key may be a symmetric key usedfor both encryption and decryption of data such that the browser and RPAmay send and receive messages using the same master secret key. As aresult of establishing a master secret key at both the browser and theRPA, a secure session is initiated and signals may then be transferredback to the HTTP session.

Once created, the master secret key (MS.sub.1) may then be utilized toencrypt a GET command from the browser to the RPA to instruct the RPA toget, for example, a web page file at www.amazon.com/image1. The RPA maynow have everything it requires to begin communicating with the hub,including the original web server location, for example, amazon.com,contained in the connect message together with the location onamazon.com of the file contained in the GET message. Accordingly, theRPA may then initiate a connection across the satellite communicationsystem to the hub server as follows.

Again referring to FIG. 7B, when the browser is activated in the remoteclient terminal, a tunnel may be established across link A2. Thus, oncethe RPA has the connect address, as well as the connect location, bothextracted from the GET message, it may forward this information inpackets of data across the tunnel on link A2 to the hub page acceleratorlocated in the hub node portion. With respect to FIG. 7B, the link A2may or may not be encrypted depending on the particular configuration ofthe over the air communication channel. In the most preferredembodiments, encryption may be used and, in particular, a tunnelingencryption algorithm may be employed such that the link A2 is secured.For example, in Gilat's 360 e, an encryption algorithm is utilized ontop of a direct video broadcast technique.

Specifically, access to the web server or internet computer 817 may beinitiated by incorporating information collected by the RPA through theconnecting GET message and encapsulating that information in a tunneledmessage to the HPA containing the information necessary to access a webpage on the remote web site. The information assembled by the RPA,including the connect information and the GET page information as wellas the HTTP normal information, may be assembled in a “NET CONNECTPACKET.” As illustrated in FIG. 9, the NET CONNECT PACKET may betransferred over the satellite via the tunneling connection to the HPAand the following processing may occur.

At the HPA, the first step in this exemplary embodiment may be to removethe header corresponding to a request for a SSL connection with aparticular remote web server, “amazon.com” in the previous example.Typically, port 443 may be utilized to request a secure SSL connection,in accordance with one exemplary embodiment of the invention.Alternatively, the identity of the port to be used in the communicationmay be passed to the browser. Currently, in this exemplary embodiment,HPA 803 located in hub node 801 includes a proxy server. The proxyserver may provide typical domain name services such as look up of IPaddresses associated with particular web servers as well as pre-fetchingand other functions which may be incorporated directly into the hub, ormay alternatively be implemented via a proxy server. Where a proxyserver is implemented, the SSL session may set up between the HPA andthe web server through the proxy server.

Returning to FIG. 9, initially the HPA may build a CONNECT message inaccordance with HTTP protocol, for instructing the proxy to connect tothe web server, using the information extracted from the NET CONNECTPACKETS received from the RPA. For example, a CONNECT message may besent from the hub page accelerator in response to the NET CONNECT packetasking for a connection to, for example, amazon.com. The proxy servermay then attempt to establish a connection with the web server, usingstandard TCP handshaking which includes at least transmission of asynchronization signal (“SYNC” signal). The proxy server might receive a“SYNC ACK” signal, and transfer an “ACK” signal back to the web serverestablishing a connection with the target web site, for example,amazon.com. Once the proxy server has established the connection an “OK”signal may be transmitted back to the hub page accelerator 803. In theevent that there is no connection made to the web server, the HPA willinstruct the RPA that the connection was not possible, and the RPA willthen inform the browser that the connection was not correctly made. Thebrowser may be reset accordingly. Alternatively, the RPA may proceedwith the transmission using a standard communication, without thebenefit of acceleration. If the connection through acceleration is notpossible, a bypass transmission may be performed. Where there is asuccessful connection, however, the processing may continue as follows.

In a manner similar to that described with respect to the communicationsbetween the browser and the RPA, establishment of a secure connectionmay require verification steps and transmission of a premaster secretkey from the HPA to the web server. As previously described, the webserver “HELLO” typically includes a server certificate. In accordancewith SSL protocol of one exemplary embodiment, the certificate containsthe server's public key, the dates for which the certificate is valid,the certificate's serial number, the server's host name, theCertification Authority's (CA) host name, and the CertificationAuthority's signature. Such a certificate transmitted from the webserver may be verified by the HPA in a verification process. Of course,the verification steps may be skipped and the data necessary forcontinuing the communication between the HPA and the web server may beextracted for use in further communications. Where the web serverrequests a certificate from the browser, the HPA may generate and maytransmit a certificate in a manner similar to that previously describedwith respect to generation of certificates by the RPA.

Information, including the public key extracted from the certificatetransmitted to the HPA from the web server, may be utilized by the HPAto generate a secure session between the web server and the HPA. In theinitial handshaking steps following the verification step, there may bea similar exchange of information as that exchanged between the browserand the web server in a corresponding set of steps. For example, thecipher scheme may be selected and information identifying the selectedscheme may be exchanged. Also, a premaster secret key may be generatedand transmitted. Through the exchange of random numbers and premastersecret keys, the HPA and the web server may establish a symmetric mastersecret (MS.sub.2) key which may be resident in both and used forencryption and decryption. Having determined the master secret key, anSSL session may be initiated between the HPA and the web server. Datareceived by the HPA over the satellite communications system may then bereformatted for transmission to the web server over the newlyestablished SSL connection.

In one embodiment, once the secure connection has been established, theproxy server may merely serve as a pass through device. For example, themaster secret key may be utilized to encrypt a GET command originallytransmitted by the browser and intercepted by the RPA. The RPA mayforward that request to the HPA which encrypts the data using the mastersecret key and forwards that request to the web server. Thus, after theestablishment of a secure connection, the proxy thereafter may serveonly as a pass-through entity. As such, requests from the HPA may bepassed through the proxy to the web server and answers from the webserver may be transferred through the proxy to the HPA.

The preceding description of an exemplary embodiment of the invention,one involving a secure communication over a satellite communicationsystem, described a communication employing the SSL protocol. However,the description is not intended to limit the scope of the invention. Anynumber of secure protocols may be used in a manner consistent with thedescribed invention. Furthermore, while the preferred embodimentdescribed an encoding technique in which the data may be encoded usingpublic-key cryptography, any number of ciphers may be used in accordancewith the invention without departing from the scope of the claimedinvention. It should also be appreciated that modifications,substitutions, additions or omissions of various components recited inthe preceding description can also be made without departing from thetrue spirit and scope of the invention. As noted, the secure protocolacceleration technique may be configured as part of the remote terminaldevice, may be incorporated directly into an indoor unit, such as amodem coupled to a satellite dish, may be a software module implementedas a driver in a remote terminal, or may be incorporated in any mannerconsistent with utilization of the invention as described. Whenincorporated into the indoor unit, the PC client software requires nomodification. In this embodiment, the modem may provide completelytransparent secure protocol acceleration. Alternatively, an embeddedplug-in module may be utilized to provide secure protocol accelerationdirectly, through the use of the client PC.

As previously described, the secure protocol acceleration module may beresident both at the remote terminal and in the hub. In a manner similarto the system and method previously described with respect to the remoteterminal, secure protocol acceleration and/or acceleration may also belocated in the hub node. Thus, a hub server may have a multi-threadedclient that can handle any number of remote units and/or may alsoinclude acceleration hardware that would enable high speed secureaccess. The system may include a rack mount unit having several secureprotocol hardware devices plugged in to the rack mount unit. In thismanner, the hub may provide acceleration services for a multitude ofremote clients.

An additional aspect of the invention includes the generation ofcertificates for establishing a secure connection between, for example,a browser and a web server, while in fact those devices may becommunicating through intermediaries, the RPA and HPA, coupled through asatellite communication system. For example, the RPA may be responsiblefor ensuring that the browser receives certificates, and may generatesuch certificates for transmission to the browser.

Distributed Certificate Sharing

In an exemplary embodiment of the invention involving protocolsrequiring certificates, certificates may permit the source and therequesting devices to authenticate one another by verifying theirrespective identities as participants in a communication, and therebyenable encrypted and secure transfers between the source and thedestination. In accordance with SSL protocol, for example, thecertificate may contain the server's public key, the dates for which thecertificate is valid, the certificate's serial number, the server'sdistinguished name (DN), the Certification Authority's (CA) DN, and theCertification Authority's signature, and may omit any of the precedingor include other information as well. A distinguished name (DN) may be aseries of name-value pairs that uniquely identify an entity. Thecertificate may also include information describing the cipher used tocreate the digital signature. The digital signature for a givencertificate may typically be generated by encrypting the data of thecertificate with the CA's private key.

The concept of distributed certificate sharing may involve thegeneration of multiple certificates for links, or sub-links within eachlink which each may require a certificate, between the componentsemployed in the communication system. In accordance with the exemplaryembodiment illustrated in FIG. 7B, certificate sharing at the A1 linkmay occur between the browser and the RPA, a second exchange ofcertificates may occur across the tunneled connection A2, and a thirdcertificate sharing may take place between the hub location and the HPAand the remote web server. To reduce latency, the second exchange ofcertificates across the satellite communication system may be avoidedthrough the use of protocols other than the secure SSL protocol. Thus,the use of distributed certificate sharing may facilitate the transferof the web server certificates, and the identification of the webserver, across the tunneled network A2 to the web browser via the RPA,and vice versa. The transfer of master secret keys MS.sub.1 andMS.sub.2, as shown in FIG. 9, is representative of master keys generatedas the result of certificate sharing.

Although a certificate returned to the browser from the RPA, in link A1,may indicate a connection to the web server, for example, amazon.com,there may not be a direct connection between the browser and the webserver, much less the HPA and the RPA. Moreover, the certificateexchange between the HPA and the web server may be transmitted through aseparate encrypted connection from that of the certificate exchangebetween the RPA and the browser. Thus, although the browser may receivean indication that suggests the browser is communicating with the remoteweb server, there may in fact be no direct link between the two, and thecertificate received at the browser may not be transmitted thecertificate generated by the web server, and the certificate received atthe web browser may not be the certificate generated by the server, ifnecessary. Nevertheless, because the browser receives a certificateindicating that the certificate was generated by the web server ofinterest, the browser may determine that it is communicating with theweb server, when in fact it may be communicating with an RPA which maybe located proximate the browser location. In the technique of thisexemplary embodiment, acceleration of the secure protocol data viageneration of a certificate and transmission to the browser on link A1illustrated in FIG. 7B, may provide a unique implementation of securecommunications. This implementation may operate as follows.

To successfully maintain a secure connection between a browser and a website employing any secure protocol requiring a certificate, the RPA maybe provided with a certificate authority. This certificate authority inthe RPA might be, for example, a Spacenet Certificate Authority.Ensuring that the browser recognizes the certificate authoritytransmitted from the RPA as a recognized certificate authority may beaccomplished through a number of techniques, including at leastregistration of the certificate authority utilized in the RPA, throughuse of a currently-recognized certificate authority such as Verisign™,dynamically as discussed post, among other techniques.

Certificates may be created using any standard tool. As noted,certificates are typically valid for a certain period of time and mayinclude various extensions in the certificate. The certificate may becreated using, for example, a signature algorithm, a public key, asubject identifier and/or authority identifier. Through the use of theimportation button, the user may then import as a trusted certificateauthority any suitable certificate authority from the RPA, such as oneprovided by Spacenet and/or any other satellite or wireless provider.

In alternative embodiments, the designation of Spacenet and/or any othersatellite or wireless provider may be incorporated manually, or thedesignation may be automated such that the certificate authority isautomatically imported. In alternative embodiments, the certificateauthority of the satellite and/or wireless network may be preregisteredand incorporated into the browsers as distributed to the end users. Thecertificate may present a security alert when, for example, thecertificate is either (a) not from a trusted certifying authority, (b)the certificate date is not valid, or (c) the security certificate isinvalid or does not match the name of the site, or based on any numberof checks. In the event that the certificate is invalid, the user mayalternatively view the certificate. When viewing the certificate, thecertificate may present the entity that issued the certificates, such asa web site, for example, amazon.com. Additionally, the certificate mayidentify the issuing authority, for example, Spacenet, Inc., and thedates for which the certificate is valid.

For a connection to a secure site, the web browser might typicallyinclude in the address designation the “HTTPS:” window, where the “S”stands for a secure link. For example, the address window might display“https://amazon.com”, indicating a secure link with amazon.com. As afurther indication of a secure link, the web browser may alternativelyinclude a depiction indicating that the communication is a securecommunication, for example, the bottom right-hand corner of the displaymight include a picture of a lock which is closed, indicating that theconnection is in fact, currently secured or providing any number ofindications.

Absent secure protocol acceleration, processing time for accessing asecure web page over a satellite communications system may be noticeablyincreased. For example, various images contained in a typical web pagemay appear slowly over time, often one image of the page appearing afterthe next. In the acceleration mode, the web page may appear complete insubstantially shorter amount of time. This effect may be due in part tothe fact that using an RPA accelerator, for example, the number of GETssent over the tunnel may be reduced to a single GET request, whereas thenumber of GETs actually transmitted by the browser, but intercepted bythe RPA, may be a far greater number.

In accordance with the invention, the total number of URLs received fromthe tunnel may be 12, whereas the total image pre-fetched from thetunnel may also be 12. The total number of URLs received from the tunnelmay be the number of URLs pre-fetched from the HPA and then forwardedfrom the tunnel to the RPA, which then may be forwarded to the browserupon request. In certain circumstances, the RPA may receive pre-fetchedimages which are not sent to the browser. In this circumstance, the RPAmay simply discard the pre-fetched image.

In yet another embodiment of the invention, the certificate authority inan RPA may generate a series of certificates for each of a plurality ofdifferent web server hosts. In one embodiment, the RPA may dynamicallygenerate a certificate for each web server host that is requested by thebrowser. Such dynamic generation of certificates is preferred overtechniques that generate certificates in advance because the number ofweb servers is constantly changing and it is virtually impossible togenerate all anticipated web server locations. Accordingly, a dynamicprocess is utilized to dynamically generate certificates for each webserver that the browser intends to access. In this manner, when thebrowser accesses the RPA, a certificate associated with the web servermay be generated in real time and returned to the browser. Thecertificate generated by the RPA may be cashed for future use.

The authenticity of the browser may also then be checked on the HPA sideto ensure that in fact the correct certificate has been generated by thebrowser, assuming such a certificate is necessary. In the event that theHPA obtains an invalid certificate from the RPA or browser, the errormay then be transmitted back to the RPA such that the RPA will thendisconnect from the browser. In this manner, errors from the HPA maythen be replicated to the browser via the RPA, thus achieving anaccurate representation of the secure connection.

FIG. 10 is a flowchart illustrating a simplified process for dynamicallygenerating a certificate. In the dynamic creation of the certificate,the protocol may incorporate an initial connect message indicating theserver is to be connected to the browser. Upon receipt of the connectmessages, illustrated as step 1001, the RPA may dynamically create acertificate signed using its own certificate authority for the indicatedweb server, which may include a public and private key if a validcertificate does not already exist, as shown in step 1002. In this case,the web server may be, for example, amazon.com. Thus, the unsignedcertificate created in step 1003, may be the certificate for amazon.com,which may be created locally in the RPA, and may contain the informationpreviously described. In the generation of the certificate, which maypreferably be performed dynamically, the last step requires thecertificate authority to sign the certificate using certificateauthority's signature, as illustrated in step 1004. However, as noted,any certificate authority which may be recognized by the browser mayalternatively be utilized.

In the secure communication protocol of FIG. 9, after the CONNECTmessage has been received by the browser, an “OK” message may be sentfrom the RPA to the browser. The “HELLO” message may be transmitted bythe browser to the server/RPA in response to the “OK” message, and maybe detected as shown in step 1005 of FIG. 10. The time required for thishandshaking to take place may be used by the RPA to dynamically generatethe appropriate certificate, and thereby perform steps 1003 and 1004 ofFIG. 10. Then, once the RPA receives a “HELLO” signal from the browser,and once the certificate is complete, the RPA may generate a server“HELLO” including the signed certificate, as illustrated in step 1006.Accordingly, due to the delay of the handshake, and the use of this timeto generate a certificate as described with respect to this exemplaryembodiment, no additional overhead time may be required for the dynamicgeneration of the certificates in the RPA. Thus, one aspect of theinvention may include the dynamic creation of certificates whilehandshake is progressing.

As described, in response to the “OK”, a client “HELLO” is sent from thebrowser to the RPA, not shown. In step 1006, the RPA then follows with aserver “HELLO”, which contains the certificate that was generated, forexample, during the delay of the “OK” and client “HELLO” handshakebetween the browser and the RPA. Of course, generation of a validcertificate may occur at any time before it is needed by the RPA tomaintain efficient communications.

When the browser receives the certificate, a check may be made to ensurethat the host name supplied by the certificate is in fact the same asthe host name requested by the browser. Additional checks may includethe date of the certificate to ensure that the certificate is still avalid certificate. Thus, in the dynamic creation of the certificate,care may be taken to ensure that the certificate is created with a validdate, if necessary. In an additional step of the verification process,the browser may ensure that the certificate from the RPA was in factcreated by an authorized certificate authority.

Where a new certificate authority is utilized in the dynamic creation ofcertificates, such as the addition of Spacenet to the list of approvedauthorities, that process may include for automatically adding Spacenetto the list of approved authorities and/or guiding the user through theprocess of installing an additional certificate authority. However, inthe most preferred embodiments, the browser does not need to have a newcertificate authority incorporated because the RPA will utilize acertificate authority pre-approved by the browser manufacturer and/or acertificate authority that may already be incorporated into the browser.In this exemplary method, the company implementing the RPA may contractwith an already approved certificate authority in order to implement anew certificate authority. For example, where the RPA is incorporatedinto an indoor unit or the like, the manufacturer of the indoor unit maycontract with a pre-approved certificate authority such as Verisign™ sothat the certificate authority for Verisign™ would be incorporated intothe indoor unit.

In alternative embodiments, the certificate authority may be authorizedin the browser. For example, in Internet Explorer™, users may accessInternet options, click on the tab “content” and identify certificates.By clicking on the certificate button, it is possible to be presentedwith a subfolder which includes an option to import a certificateauthority. The import button allows the importation of an alternativecertificate authority. Using the import button, a user may importalternative trusted route certificate authorities. By clicking on thetrusted route certificate authorities tab, the trusted route certificateauthorities may optionally be presented in the window associated withthe dialogue box. By selecting space in the view button, the informationrelevant to the certificate may be presented.

As an alternative technique to the present invention, the RPA client maybe incorporated directly into the browser. In these embodiments, theacceleration need not occur in the manner suggested, and many steps maybe avoided. By incorporating the RPA directly into the browser, a muchmore efficient connection may be utilized while still achieving theobjectives described herein. In this exemplary embodiment, a useroperating over a satellite link may select an option in an Internetdropdown tool box for either a satellite or wireless connection. Inthese embodiments, the implementation of the RPA directly into thebrowser may facilitate a substantial reduction in latency for thosedevices. For example, the user of a Palm™ hand-held device, Blackberry™hand-held device, or other portable device who may wish to reduce thedelays across the wireless network may incorporate the RPA directly intothe browser of the device. In this manner, there is no need for aseparate RPA client and the functionality of the RPA may be incorporateddirectly into the browser, which may eliminate the need for a number ofthe process steps described above. In using this technique, there may beno need for a handshake exchange between the browser and the RPA on theclient's side. The browser may simply accept the certificate as havingbeen validly returned from the web server. The browser may then becomethe RPA and requests may be sent directly to the HPA and eventually tothe web server, from the browser, bypassing any need for the RPA. Thus,the teachings of an embodiment of the present invention may acceleratewireless remote Internet connections in a variety of environments.

Security between the RPA and the HPA may be provided using standardtunneling connection across the wireless connection A2 of FIG. 7B. Inthe standard tunneling connection across A2 of FIG. 7B, the HPA and hubserver may have built-in authentication techniques for ensuring thattransmissions from the RPA are in fact coming from a particular remoteterminal device and thus can identify the source address of the remoteterminal device for forwarding to the web server. In this way, the webserver may ensure that the identity of the particular receiver iscorrect. In still further embodiments of the invention, the licensescreen which installs the browser and/or RPA software may seekpermission from the user to install an alternative certificateauthority. In this way, the user is fully informed of his legal rightswith respect to the installation of the certificate authority and thesoftware installing certificate authority seeks waiver from the user ofany legal liability associated with the inclusion of an alternativecertificate authority. Thus, embodiments of the present inventioncontemplate the business method of seeking a waiver for the installationof a certificate authority associated with the RPA for dynamicallygenerating certificates in the RPA.

In the preceding description of a preferred embodiment for theestablishment of a secure connection between a browser and a web server,the secure transmission was described as having initially beentransmitted in accordance with the Secure Sockets Layer protocol. Thepresent invention is applicable to facilitate the transmission of dataover a satellite communications system or other wireless network forwhich the communication was originally designed to be transmitted inaccordance with any secure communication protocol. Thus, the presentinvention is applicable to communications originally transmitted usingany secure protocol.

What is claimed is:
 1. A method comprising: intercepting, by a devicevia a satellite link, a plurality of connection requests from a remoteterminal; establishing, by the device, a plurality of connections withone or more servers in response to the plurality of connection requestsfrom the remote terminal; monitoring, by the device, a number of theplurality of connections that are open; receiving, by the device via thesatellite link, another connection request from the remote terminal;determining that the monitored number meets or exceeds a limitassociated with the remote terminal; and rejecting the anotherconnection request.
 2. The method of claim 1, wherein the plurality ofconnection requests, the plurality of connections, and the anotherconnection request conform to a secure protocol.
 3. The method of claim2, wherein the secure protocol is a secure sockets layer (SSL) protocol.4. The method of claim 2, wherein establishing the plurality ofconnections with the one or more servers further comprises establishinga secure tunnel between one of the one or more servers and the remoteterminal.
 5. The method of claim 1, wherein at least one of theplurality of connection requests includes a TCP segment having a SYNsignal.
 6. The method of claim 5, wherein establishing the plurality ofconnections with the one or more servers further comprises:transmitting, in response to at least one of the plurality of connectionrequests, to one of the one or more servers, a second connection requestincluding a TCP segment having a SYN signal; receiving, from the one ofthe one or more servers, a connection response including a TCP segmenthaving a SYN-ACK signal; and transmitting, to the one of the one or moreservers, a TCP segment having an ACK signal.
 7. The method of claim 1,further comprising establishing a tunnel between the device and theremote terminal, wherein the plurality of connection requests and theanother connection request are received via the tunnel.
 8. A methodcomprising: receiving, by a device via a satellite link, a connectionrequest from a remote terminal; establishing, by the device, aconnection with a server in response to the connection request;intercepting, at the device, a close connection message from a webserver; transmitting, by the device and to the server, a closeconnection acknowledge message; receiving, by the device via thesatellite link, a communication associated with the connection;re-establishing, by the device, the connection with the server; andtransmitting, via the connection, the communication to the server. 9.The method of claim 8, wherein the connection request, the connection,the close connection message, and the close connection acknowledgemessage conform to a secure protocol.
 10. The method of claim 9, whereinthe secure protocol is a secure sockets layer (SSL) protocol.
 11. Themethod of claim 9, wherein the close connection message includes a TCPsegment having a FIN signal.
 12. The method of claim 11, wherein theclose connection acknowledge message includes a TCP segment having anACK signal.
 13. The method of claim 8, wherein establishing theconnection with the server further comprises: transmitting, to theserver and in response to the connection request, a second connectionrequest including a TCP segment having a SYN signal; receiving, from theserver, a connection response including a TCP segment having a SYN-ACKsignal; and transmitting, to the server, a TCP segment having an ACKsignal.
 14. A method comprising: receiving, via a satellite link, a webpage containing references to a plurality of objects; displaying the webpage without the plurality of objects; delaying a transmission of one ormore requests for the plurality of objects until a period of timeelapses after displaying the web page; receiving an input requesting asecond web page before the period of time elapses; and canceling thedelayed transmission of the one or more requests.
 15. The method ofclaim 14, wherein displaying the web page comprises displaying a portionof the web page.
 16. The method of claim 14, wherein the plurality ofobjects comprise picture, video, or audio objects.
 17. The method ofclaim 14, further comprising: displaying the second web page beforetransmitting one or more requests for a second plurality of objectsreferenced in the second web page; responsive to a second period of timeelapsing after displaying the second web page, transmitting, via thesatellite link, one or more requests for at least some of the secondplurality of objects; and receiving the second plurality of objects. 18.The method of claim 17, wherein receiving the second plurality ofobjects comprises receiving, via the satellite link, a compressedcluster containing the second plurality of objects.
 19. The method ofclaim 17, wherein receiving the second plurality of objects comprisesreceiving at least one of the second plurality of objects from a localcache.
 20. The method of claim 14, wherein the period of time is lessthan one second.